home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-dns-idpr-02.txt
< prev
next >
Wrap
Text File
|
1993-10-26
|
8KB
|
223 lines
Network Working Group R. Austein
INTERNET-DRAFT Epilogue Technology Corporation
October 1993
DNS Support for IDPR
[draft-ietf-dns-idpr-02.txt]
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress." Please check the 1id-abstracts.txt
listing contained in the internet-drafts Shadow Directories on
nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au to learn the current status of any Internet Draft.
This is a working document only, it should neither be cited nor
quoted in any formal document.
This document will expire before 27 April 1994.
Distribution of this document is unlimited.
Please send comments to the author.
1. Introduction
This note documents the support needed from the Domain Name System
(DNS) by Inter-Domain Policy Routing (IDPR). The DNS changes are
minor and can be deployed with minimal impact on the installed DNS
community.
When an IDPR Policy Gateway receives an IP packet, it needs to map
the packet's IP address to an IDPR Administrative Domain (AD) in
order to deliver the packet. The initial prototype implementation of
IDPR used a configuration file to provide this mapping, but this is
clearly unacceptable for a full-scale deployment of IDPR. As an
existing, well understood, (relatively) low-overhead distributed
database, the DNS is the obvious mechanism by which to distribute
Austein Expires 27 April 1994 [Page 1]
INTERNET-DRAFT DNS Support for IDPR September 1993
these mappings.
Due to an unfortunate collision in use of the term "domain" by both
IDPR and the DNS, this note avoids unqualified use of the term
"domain."
2. The AD RR type.
We define one new DNS RR type, with symbolic name "AD" and numeric
value xxx. This RR type is class-independent; the rest of this note
discusses IN class AD RRs, with the understanding that the mechanism
described here is not tied to IP addresses. The RDATA portion of an
AD RR consists of two 32-bit integers, each representing an IDPR AD.
The two fields are the "home" AD associated with the address, and the
proxy AD associated with the address. An AD which is acting as its
own proxy (the normal case) has the same value for these two fields.
When written in a master zone file, these fields are written as
unsigned decimal integers; no characters other than the digits zero
through nine may appear in these fields. The "proxy" field may be
omitted, in which case its value is the same as the "home" field.
Class IN AD RRs appear in the IN-ADDR.ARPA portion of the DNS name
space. These RRs are used to map from an IP address to an IDPR AD.
Since the IN-ADDR.ARPA portion of the DNS name space is (or should
be) already populated with PTR RRs mapping IP addresses to DNS names,
the DNS wildcard name mechanism will not generate AD RRs for IP that
have associated PTR RRs. However, since not all IP addresses have
associated DNS names, it will probably be useful to add wildcard AD
RRs to master files where appropriate to insure that there is a
"default" AD associated with every IP address on a given IP network
or subnetwork.
For purposes of discussion, assume that Miskatonic University is in
Administrative Domain 42, while Engulf & Devour, Inc., is in
Administrative Domains 666 and 17; Engulf & Devour recently purchased
Liver Donors Ltd., in order to use their Policy Gateway as a proxy
for Engulf & Devour's corporate network. All IP addresses within
Miskatonic University are advertised as being Miskatonic's
Administrative Domain, while Engulf & Devour choses to publish
Administrative Domain information only for specific hosts. The
following RRs might appear in the DNS:
Loki.Miskatonic.EDU. IN A 1.1.1.5
Thor.Miskatonic.EDU. IN A 1.1.1.6
Liver-Donors.EaD.COM. IN A 2.2.2.7
HQ.EaD.COM. IN A 3.3.3.8
Austein Expires 27 April 1994 [Page 2]
INTERNET-DRAFT DNS Support for IDPR September 1993
5.1.1.1.IN-ADDR.ARPA. IN PTR Loki.Miskatonic.EDU.
5.1.1.1.IN-ADDR.ARPA. IN AD 42 42
6.1.1.1.IN-ADDR.ARPA. IN PTR Thor.Miskatonic.EDU.
6.1.1.1.IN-ADDR.ARPA. IN AD 42 42
*.1.1.1.IN-ADDR.ARPA. IN AD 42 42
7.2.2.2.IN-ADDR.ARPA. IN PTR Liver-Donors.EaD.COM.
7.2.2.2.IN-ADDR.ARPA. IN AD 666 666
8.3.3.3.IN-ADDR.ARPA. IN PTR HQ.EaD.COM.
8.3.3.3.IN-ADDR.ARPA. IN AD 17 666
3. Use of the AD RR type.
In the initial deployment of of IDPR, we believe that only IDPR
Policy Gateways will need to know about IDPR ADs. Thus, only Policy
Gateways will need to obtain and use AD RRs. In the long run it may
be beneficial for hosts to obtain this data as well, but it is not
necessary that they do so in order for IDPR to work correctly.
4. Bootstrapping the Policy Gateways
Since a Policy Gateway needs an AD before it can forward a packet,
the AD associated with the IP addresses of each of the Policy
Gateway's default DNS name servers needs to be part of the Policy
Gateway's configuration. Ie, there is a bootstrapping problem here,
because we can't use the DNS to obtain the ADs we need in order to
talk to the DNS. Note that the Policy Gateway's default DNS name
servers are not necessarily the root DNS name servers; indeed, clever
use of centralized DNS caches by a community of Policy Gateways will
help decrease the load IDPR will add to the existing DNS system.
Ultimately, however, this question reduces to the question of how the
Policy Gateways reach the DNS root servers.
5. Glue RRs
Since in some cases the authoritative nameservers for a particular AD
RR may be within the AD itself, it may be necessary to insert "glue"
AD RRs into some zones in the IN-ADDR.ARPA tree. These fill the same
role as the glue A RRs already in use to solve the analogous problem
with finding the IP address of a name server.
6. Security Considerations
Security considerations ane not discussed in this memo.
7. Acknowledgments
Most of the ideas in this document were derived from email
conversations with Martha Steenstrup and Robert Woodburn, without
Austein Expires 27 April 1994 [Page 3]
INTERNET-DRAFT DNS Support for IDPR September 1993
whose help the author would still be completely clueless about IDPR
and its requirements. Thanks also to Mike Patton for catching a
serious error in the way that an earlier draft of this document
proposed to use DNS wildcard names.
8. References
[1] Steenstrup, M., "An Architecture for Inter-Domain Policy
Routing", RFC 1478, June 1993.
[2] Mockapetris, P., "Domain names - concepts and facilities", RFC
1034, November 1987.
[3] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, November 1987.
[4] Lottor, M., "Domain administrators operations guide", RFC 1033,
November 1987.
9. Author's address:
Rob Austein
Epilogue Technology Corporation
268 Main Street, Suite 283
North Reading, MA 01864
USA
Phone: +1-617-942-0915
EMail: sra@epilogue.com
Austein Expires 27 April 1994 [Page 4]